Setting Up Auditing via T-SQL
Alternatively, you can set up auditing with T-SQL statements and also switch the audit off and on using the ALTER SERVER AUDIT command by using WITH (STATE=ON) or WITH (STATE=OFF), as shown in Listing 1.
Listing 1. Setting Up Auditing with T-SQL
/* Create the SQL Server Audit object, and send the results to the
Windows Application event log. */
USE master;
go
CREATE SERVER AUDIT NEW_SQL_Server_Audit
TO APPLICATION_LOG
WITH ( QUEUE_DELAY = 1000, ON_FAILURE = CONTINUE);
GO
/* Create the Database Audit Specification object using an Audit event */
USE AdventureWorks2008R2;
GO
CREATE DATABASE AUDIT SPECIFICATION NEW_Database_Audit_Specification
FOR SERVER AUDIT NEW_SQL_Server_Audit
ADD (SELECT
ON OBJECT::[HumanResources].[Employee]
BY [public])
WITH (STATE = ON);
GO
/* Enable the audit. */
USE master;
go
ALTER SERVER AUDIT NEW_SQL_Server_Audit
WITH (STATE = ON);
/* Test the audit is working */
USE AdventureWorks2008R2;
GO
SELECT * from HumanResources.Employee;
GO
/* Disable the audit. */
USE master;
GO
ALTER SERVER AUDIT NEW_SQL_Server_Audit
WITH (STATE = OFF);
GO
|
It
is recommended that you create your audit specifications with scripts
so that you can easily manage them and not have to re-create them via
SSMS dialogs.
SQL Injection Is Easy to Do
SQL
injection is the number-one security vulnerability globally as reported
and tracked by the Open Web Application Security Project (OWASP; www.owasp.org).
Because of this continued vulnerability, we decided to show you how to
do SQL injection. However, keep in mind that we are showing you how to
do it so that you can prevent this situation from happening to you. You
need to make sure you include the vulnerability checks as a part of your
coding and design reviews. Then this will never happen to you.
If you have a typical .NET
forms application that prompts users to provide filter criteria to
locate information, this is often a perfect place for hackers to add
their own malicious code to do damage. Even your own employees might be
hackers or want to cause harm. We call these folks “Evil SQL’ers.”
The most common way SQL
injection occurs is with the direct insertion of code into a variable
that is part of a SQL statement. In other words, a user-defined variable
is concatenated with a partially defined SQL statement and then
subsequently executed as part of the application. The hacker adds a
terminating character to the first part of the input and then follows it
up with his or her own destructive SQL statement.
Let’s consider the
following simple Contact Name search application as an example. A .NET
forms application might define a variable called ContactFirstName
and then prompt the end user for a value to search for any contact’s
first name that begins with a set of characters such as “Don.” Such an
operation might result in finding “Don,” “Donald,” and “Donny” matching
rows. The code might look like this:
var ContactFirstName;
ContactFirstName = Request.form ("ContactFirstName");
var sql = "SELECT * FROM [AdventureWorks].[Person].[Contact]
WHERE [FirstName] like '" + ContactFirstName + "%'";
The subsequent SQL code that would be submitted to SQL Server for execution would be as follows:
SELECT * FROM [AdventureWorks].[Person].[Contact]
WHERE [FirstName] Like 'Don%';
This code works perfectly.
To test this code as if you are an “Evil SQL’er,” create a table named XtraContactsTable
that you can pretend is your primary contacts table where all your
company’s contacts are stored. Go ahead and create this empty table for
this evil test. The simple CREATE statement could be
CREATE TABLE [dbo].[XtraContactsTable]
([ContactFirstName] [nchar](10) NULL) ON [PRIMARY];
To be really evil, attempt to
drop this table and cause severe damage to this company using the SQL
injection method. Now, at the applications prompt for a contact first
name, you, acting as the evil SQL’er, can instead type the following:
Don'; drop table [dbo].[XtraContactsTable] --
The subsequent SQL code that is sent to SQL Server for execution is
SELECT * FROM [AdventureWorks].[Person].[Contact]
WHERE [FirstName] Like 'Don%';
drop table [dbo].[XtraContactsTable] --
The first part of the query is executed, followed by the DROP TABLE
statement. Try this with the table you just created. After you execute
the entire “valid” SQL statement, you see rows returned from the first
part of the query, and the drop of the XtraContactsTable is also executed. If the evil code had simply used the Employee table name or the Contact table name, all your company’s most sacred data would be gone in a flash.
That is SQL injection! It is
easier to do than you think. And now you know how to do it, which means
you must also prevent this and other SQL injection vulnerabilities from
the beginning. In this case, you should write code to reject quotation
marks, specific delimiters (such as ;), and comment characters such as - - and /*...*/. We have included this SQL code example on the CD with this book as well.
Another popular method by Evil
SQL’ers is to put a nasty piece of code into text or char data that will
be stored as data in a table. When (or if) the data is ever used as
part of a SQL statement (and concatenated to SQL code as just
demonstrated), the code in the data is executed. Pretty tricky! Sort of
like a time bomb waiting to explode.
